The present invention relates to telecommunications and, more particularly, to management of group membership information for instant messaging, group conferencing and the like. The invention is particularly useful with respect to wireless communication devices such as cell phones and wirelessly-equipped personal digital assistants (PDAs), but the invention can extend as well to apply with respect to other sorts of communication devices.
In an exemplary wireless communication system, each mobile station may communicate via an air interface with a base transceiver station (BTS) and in turn with a base station controller (BSC). The BSC may then be coupled with a mobile switching center (MSC). Further, the BSC may be coupled with packet data serving node (PDSN) or other gateway, which may provide connectivity with an IP network, such as the public Internet or a private intranet (e.g., a wireless carrier's core IP network). The mobile station may thus communicate with entities on the IP network via a communication path comprising the air interface, the BTS, the BSC and the PDSN.
A mobile station can initiate packet-data communication by sending an initiation request message over an air interface access channel, and via the BSC, to the MSC. Applying industry standards, the initiation request message may include a “packet data” service option code that characterizes the requested communication as packet-data communication, as compared with traditional voice communication. When the MSC receives the initiation request, it may then detect the “data” service option code and responsively send the message back to the BSC for handling.
In turn, when the BSC receives the initiation request from the MSC, the BSC may establish a radio link layer connection with the mobile station, by assigning the mobile station to operate on a particular traffic channel over the air interface (e.g., a fundamental traffic channel, and perhaps one or more supplemental channels). In addition, the BSC may pass the initiation request to the PDSN. And the PDSN and mobile station may then negotiate with each other to establish a data-link layer connection, typically a point-to-point protocol (PPP) session over which packet data can be communicated between the mobile station and the PDSN.
As part of this process, the mobile station may obtain an IP address, to facilitate packet communications. For instance, the PDSN may assign an IP address to the mobile station, or the PDSN may communicate with a mobile-IP “home agent” to obtain an IP address for mobile station.
(Note that it may also be possible for a mobile station to engage more directly in packet-switched communications, rather than communicating packet data through a channelized PPP connection. For instance, the BTS itself might sit as a node on an IP network, and the mobile station might send and receive individual packets via the BTS.)
A mobile station, like other packet-data terminals, can be further equipped to communicate real-time media, such as voice and/or video. For instance, the mobile station may include one or more media input mechanisms, such as a microphone or video camera, and may further include logic to digitize, encode and packetize media received through those mechanisms. Additionally, the mobile station may include logic to encapsulate the resulting packets with industry standard Real Time Protocol (RTP) headers and to transmit the resulting RTP packets to one or more designated addresses on the IP network.
Similarly, the mobile station may include logic to receive incoming RTP packets from the IP network, to assemble the packets in sequence, and to depacketize and decode the data carried by the packets so as to retrieve an underlying media signal. Further, the mobile station may include one or more media output mechanisms, such as a speaker or video display, through which to play out the incoming media signal to a user.
In order for a mobile station to establish RTP communication with another endpoint, the two endpoints will usually engage in setup signaling, which may take a variety of forms. For instance, according to the industry standard Session Initiation Protocol (SIP), an initiating endpoint may send to a SIP proxy server a SIP “INVITE” request message that designates a terminating SIP address. The INVITE may include a Session Description Protocol (SDP) block that characterizes the proposed session as an RTP session.
The proxy server may then query a SIP registry to determine an IP address of the terminating endpoint. And the proxy server may then forward the INVITE to that address. If the terminating endpoint agrees to establish the session, the terminating endpoint may then send a SIP “200 OK” message via the proxy server to the initiating endpoint. And the initiating endpoint may responsively send a SIP “ACK” message via the proxy server to the terminating endpoint. The endpoints may then begin to communicate RTP packets with each other.
Another way for two or more endpoints to establish and conduct a real-time media session with each other is through a communication server (e.g., a multipoint conference unit (MCU)). The communication server may function to set up respective RTP sessions (“legs”) with each participating endpoint and to bridge together the legs so that the participants can communicate with each other.
For instance, an initiating endpoint may send to a proxy server an INVITE that requests an RTP session with one or more designated terminating endpoints, and the proxy server may forward the INVITE to the communication server. The communication server may then respond with a 200 OK to the initiating endpoint, and the initiating endpoint may respond with an ACK, thus establishing an RTP leg (initiating leg) between the initiating endpoint and the communication server.
At the same time, the communication server itself may send an INVITE via the proxy server respectively to each designated terminating endpoint and establish RTP legs (terminating legs) with each of those other endpoints. In turn, the communication server may bridge together the initiating leg with each of the terminating legs, so as to allow all of the endpoints to communicate with each other.
By establishing real-time media sessions in this manner between mobile stations, a wireless carrier can conveniently provide its subscribers with PTT service. In particular, each “PTT-capable” mobile station can preferably include a talk button or other actuating mechanism that a user can engage in order to initiate a PTT session with a designated group of one or more other users. When the user presses the PTT button, a PTT client application on the mobile station may responsively send an INVITE request to a proxy server. And the proxy server may forward the INVITE to a PTT server. An SDP block in the INVITE request may identify or list a “communication group” for the user, i.e., a group of other users with whom the initiating user would like to communicate. The PTT server may then set up RTP legs with the initiating user and with each member of the group. And the PTT server may then bridge together the communication legs in a designated manner, so as to allow the members of the group to communicate with each other and with the initiating user.
To simplify the initiation of PTT communications, the mobile station of the initiating user may be provided with a group list that identifies other mobile stations with which communications may be initiated. Instead of entering a SIP address or other contact address of another PTT-enabled mobile station, an initiating user may select a mobile station or communication group from the partition list and then engage the talk button to talk with the selected mobile station or communication group.
Group lists may be useful to allow team members working together on a project to contact one another with minimal delay. However, when individuals in various teams are frequently added or removed, group lists can become difficult and inconvenient to keep up to date.
In a group communication system, such as a PTT system or an instant messaging (IM) system, group membership data is typically stored by a network-based group data store, so that network-based application servers can facilitate group communications. For example, when an IM server receives an instant message from a subscriber, destined to the subscriber's “group,” the IM server may refer to the group data store to determine which other subscribers are members of the sending subscriber's group, and the IM server may then distribute the instant message to each of those other subscribers. As another example, when a conference server (e.g., PTT server) receives a subscriber's request to initiate a group conference with the subscriber's group, the conference server may refer to the group data store to determine which other subscribers are members of the requesting subscriber's group, and the conference server may then invite each of those other subscribers to participate in the group conference.
Typically, a client station that is arranged to support group communications will also have a locally stored copy of group membership information. The locally stored copy can assist a user of the client station in managing communications. For instance, the user can refer to the locally stored copy to see who are members of the user's group. Further, in situations where a user is a member of more than one group, the user can refer to the locally stored copy to select a desired group with which to engage in a group communication. The locally stored copy can be used for other purposes as well.
A need exists to synchronize the locally stored copy of group membership data with the network-based copy of group membership data. In particular, if changes are made to the network-based copy of the group membership data, then an update should be sent to each affected client station, so that users of those stations can have access to the most current set of relevant group membership data.
One way to ensure that wireless client stations receive applicable updates to group membership data is for the wireless client stations to periodically request any applicable updates from a network server. For instance, each wireless client station can be set to send a query to a group data server every 10 minutes (or other time period) to obtain the latest version of the applicable group data, or to obtain any incremental update to the client station's local copy of the group data. A problem with this arrangement, however, is that such query and response messaging by many wireless client stations in a given region can tend to overload the wireless communication infrastructure.
To avoid such excessive messaging, another solution is to have the group data server push updates to affected wireless client stations whenever such updates occur, i.e., on an as-needed basis. For instance, the group data server could send the updates to the affected client stations in the form of SMS messages (e.g., one or a series of SMS messages). Or the group data server could send SMS-based alert messages (e.g., WAP-push or MMS messages) to the affected client stations, to cause each client station to send an update request to the group data server, and to then receive the group data update.